Internet Surfer 2.0

home *** CD-ROM | disk | FTP | other *** search

/ Internet Surfer 2.0 / Internet Surfer 2.0 (Wayzata Technology) (1996).iso / pc / text / mac / faqs.281 < prev next >

Wrap

Text File | 1996-02-12 | 27.7 KB | 657 lines

Frequently Asked Questions (FAQS);faqs.281 2. TeX Utilities There are many TeX font utilities. For TeX related questions, I direct you to comp.text.tex or the Info-TeX mailing list. I will happily list any utilities here that the comp.fonts public feels should be present. I am listing MetaFont because it is the obvious font-specific component of TeX and PKtoSFP because it allows anyone to use PS2PK to create LaserJet softfonts. Liam R. E. Quin <lee@sq.com> is the original author of the MetaFont section. It has been hacked at a bit by norm to make it fit the tone of the comp.fonts FAQ. Assume that norm is responsible for any errors, not Liam. 2.1. MetaFont 2.1.1. About MetaFont: Metafont is a programming language for describing fonts. It was written by Donald Knuth and is documented in Computers & Typesetting/C: The METAFONTbook Knuth, Donald E. Addison Wesley, 1986 ISBN 0-201-13445-4, or 0-201-13444-6 (soft cover) Library access: Z250.8.M46K58, or 686.2'24, or 85-28675. A font written in MetaFont is actually a computer program which, when run, will generate a bitmap (`raster') for a given typeface at a given size, for some particular device. 2.1.2. What do you need in order to use the fonts: You cannot print the MetaFont fonts directly (unless you want a listing of the program, that is). Instead, you must generate a bitmap font and use that to print something. If you are using TeX, the sequence of steps is something like this: MF -> metafont -> GF [ convert MetaFont program TFM into a bitmapped font ] GF -> gftopk -> PK [ represent the bitmapped font efficiently ] TEX -> tex -> DVI [ convert TeX document into TFM device independent output ] DVI -> dvi2xxx -> XXX [ convert DVI to output device PK format ] XXX -> printer -> hardcopy [ print the dvi2xxx output ] The above steps are idealized. In reality, you have to make sure that the fonts get installed in the correct places and you may have to adjust description files, etc. The friendly folks on comp.text.tex can probably get it staightened out for you if you can't find a local guru. If you are not using TeX, it's almost impossible to predict. At some point in the above sequence, you'll insert some other conversion program and proceed differently. Here, for example, is how you might use TeX fonts with WordPerfect and a LaserJet printer. PK -> PKtoSFP -> SFP [ PK to LaserJet softfont ] SFP -> SFP2Auto -> TFM [ Make HP AutoFont TFM file ] SFP -> PTR -> installation [ Install the fonts into WP ] TFM Use WordPerfect as you normally would. 2.1.3. How to use Metafont fonts with Troff If, when you run troff, you get the message `typesetter busy', you have the original Ossanna-troff, also called otroff. Chris Lewis has a package which will let you use TeX fonts with troff -- it's called psroff, and comes with documentation. ftp: gatekeeper.dec.com (16.1.0.2) pub/misc/psroff-3.0 ftp: ftp.cs.toronto.edu [128.100.1.105] pub/psroff-3.0/* If, when you run troff, you get something like this: x T 300 x res 300 1 1 you have ditroff. This is sometimes called titroff or psroff. In this case, you will probably need to do the following: 1) convert the font to your printer's format 2) generate a width table for the font 3) add the font to the DESC file for the appropriate device 4) arrange for troff to download the font 5) tell troff about the font by running `makedev DESC' in the right place. If, when you run troff, you get something like this: X hp(SCM)(CM)(AF)(AD) 300 1 1 Y P default letter 2550 3300 0 0 90 90 2460 3210 you have sqtroff: 1) convert the font to your printer's format 2) generate a width table for the font 3) add the font to the DESC file for the appropriate device 4) put the font in the appropriate raster directory 5) tell sqtroff about the font by running `sqmakedev DESC' or `sqinstall'. In each case, you should be able to get help from your vendor. Note that Chris Lewis' psroff package has software to make width tables for troff from pk files. 2.1.4. Converting between font formats Conversions to and from pbm and pk format were posted to comp.text.tex and to alt.sources on the 9th of August, 1990 by Angus Duggan (ajcd@cs.ed.ac.uk). The program is pbmtopk, and there are also at least two patches. Chris Lewis' psroff package includes a program to go from pk both to the HP LaserJet and to PostScript. John McClain (ophelp@tamvenus.bitnet) has some conversion programs for various graphics formats to/and from pk files. A PC program, CAPTURE, turns HPGL files into PK format, US$130 from Micro Programs Inc., 251 Jackson Ave., Syosset, NY 11791 U.S.A. Metaplot can take pen-plotter files and prouce metafont files; contact wilcox@cis.ohio-state.edu Kinch Cmputer Company sell .pk fonts derived from PostScript fonts. Kinch Computer Co., 501 S. Meadow St.Ithaca, NY 14850 U.S.A. telephone: +1 607 273 0222; fax: +1 607 273 0484 2.1.5. Where to get bitmap versions of the fonts There are archives containing the bitmaps of many of these fonts at various sizes and resolutions. The fonts must have been generated for the correct print engine: e.g. write-white or write-black. The archives generally hold only the sizes used by TeX. These are `magstep' sizes, and are not exact point sizes. It is probably better to generate them from the Metafont sources yourself if you can. The best place to look for raster fonts was almost certainly mims-iris.waterloo.edu but it isn't any more, the fonts have all gone. Let me know if you find them elsewhere. Most people seem to have moved to using PostScript fonts or Bitstream ones instead now. Some other sites are: ctrsci.math.utah.edu (128.110.198.1) science.utah.edu (128.110.192.2) ymir.claremont.edu (134.173.4.23) The occasional posting of ftp sites to comp.misc and comp.archives lists these and several other sites. 2.1.6. Getting fonts by FTP and Mail If you are using ftp, you will need either the name of the host or the Internet number. For example, to connect to ymir, listed as ftp: ymir.claremont.edu [134.173.4.23] you will need to type something like ftp ymir.claremont.edu If that doesn't work, try using the number: ftp 134.173.4.23 If that doesn't work, on Unix systems you can use nslookup (it's usually /usr/etc/nslookup) to find the host number -- it might have changed. Type the entire host name, and after a few seconds nslookup will give you the address. Once you have connected, you will need to go to the appropriate directory, lists its contents, and retrieve the files. Most of the machines listed here run Unix, and you use "ls" and "cd" to list files and to change directories. Ymir runs VMS, and you will have to put square brackets around directory names, like [this]. Remember that although Metafont sources are text files, pk fonts are not ASCII, and you will have to use binary mode for them. In general, use text mode for README files and *.mf files, and binary mode for other font files. Files ending in .Z are compressed binary files -- you will need to use binary mode, and then uncompress the files when you get them. You can get files from ymir by sending mail messages to mailserv@ymir.claremont.edu For example, send [tex.mf.misc]cmapl10.mf will get the file cmapl10.mf from the directory "tex.mf.misc". You can't get binary files in this way. There is an ftp-by-mail BITNET service, BITFTP, for BITNET users. Before getting large files by mail, please remember to get permission from all intervening sites. Ask your site administrator, who can send mail to Postmaster at each site on the way if necessary. 2.2. PKtoSFP/SFPtoPK Convert fonts from TeX PK format to HP LaserJet (bitmap) format. 2.3. Metafont -> PostScript conversion There are (I believe) two programs that perform this task. At least one of them is called "mf2ps". If you have any more information about these tools, please let me know. 2.4. PostScript -> Metafont There is at least one tool for this purpose. I believe that it is called "ps2mf". If you have any more information about these tools, please let me know. 2.5. PKtoPS Included in the psroff distribution, this utility converts PK fonts into PostScript fonts (bitmaps, I presume). If you have any more information about these tools, please let me know. 2.6. PKtoBDF / MFtoBDF From the SeeTeX distribution, programs to help previewers under X11. 3. MFpic MFpic is a macro package for including pictures in TeX documents. The idea behind this package is to have Metafont do the actual drawing, and store the pictures in a font that TeX can include in the document. The macros have been designed so that the user should never have to learn Metafont to use these macros -- the TeX macros actually write the Metafont file for you. 4. GNU Font Utilities Here is a brief description of the programs included: * imageto extracts a bitmap font from an image in PBM or IMG format, or converts the image to Encapsulated PostScript. * xbfe is a hand-editor for bitmap fonts which runs under X11. * charspace adds side bearings to a bitmap font. * limn fits outlines to bitmap characters. * bzrto converts a generic outline font to Metafont or PostScript. * gsrenderfont renders a PostScript outline font at a particular point size and resolution, yielding a bitmap font. * fontconvert can rearrange or delete characters in a bitmap font, filter them, split them into pieces, combine them, etc., etc. * imgrotate rotates or flips an IMG file. We need volunteers to help create fonts for the GNU project. You do not need to be an expert type designer to help, but you do need to know enough about TeX and/or PostScript to be able to install and test new fonts. Example: if you know neither (1) the purpose of TeX utility program `gftopk' nor (2) what the PostScript `scalefont' command does, you probably need more experience before you can help. If you can volunteer, the first step is to compile the font utilities. After that, contact me (karl@gnu.ai.mit.edu). I will get you a scanned type specimen image. The manual explains how to use these utilities to turn that into a font you can use in TeX or PostScript. You can get the source by ftp from prep.ai.mit.edu [18.71.0.38]:pub/gnu/fontutils-0.5.tar.Z. And also from these other sites around the world; please check them before prep. United States: wuarchive.wustl.edu gatekeeper.dec.com:pub/GNU uxc.cso.uiuc.edu ftp.uu.net:packages/gnu Europe: archive.eu.net src.doc.ic.ac.uk:gnu ftp.funet.fi nic.funet.fi:pub/gnu ugle.unit.no isy.liu.se ftp.diku.dk elsewhere: ftp.cs.titech.ac.jp utsun.s.u-tokyo.ac.jp:ftpsync/prep archie.au:gnu You can also order tapes with GNU software from the Free Software Foundation (thereby supporting the GNU project); send mail to gnu@prep.ai.mit.edu for the latest prices and ordering information, or retrieve the file DISTRIB from a GNU archive. 5. Font editors - BDF - There is a bdf font editor that comes with HP/Apollo workstations. It's called 'edfont'. It's not the best but it works. Gary <Gocek.Henr801C@Xerox.COM> reports: The standard X distribution for X11R5 contains "xfed", which allows you to play with BDF fonts. "xfedor" has a more elaborate user interface, and is available on most contrib directories. The last time I tried: "xfedor" couldn't handle BDF files with more than 256 characters. "xfed" aborts if the BDF file contains a COMMENT line with no other text. The workaround is to edit the BDF file, to put text after the word COMMENT. A single blank space is sufficient. For some reason, the standard BDF files included in the X release contain blank spaces on the otherwise empty COMMENT lines. It was probably easier to add the space to the COMMENT lines of every BDF file than it was to fix the lex code for xfed. :-) - PK - The GNU font utilities include an X-based editor called Xbfe which edits bitmapped fonts under X. Eberhard Mattes' emTeX includes PKedit. 6. t1utils This is a snippet from the README file for I. Lee Hetherington's <ilh@lcs.mit.edu> t1utils package: t1utils is a collection of simple type-1 font manipulation programs. Together, they allow you to convert between PFA (ASCII) and PFB (binary) formats, disassemble PFA or PFB files into human-readable form, reassemble them into PFA or PFB format. Additionally you can extract font resources from a Macintosh font file (ATM/Laserwriter). -- END OF PART VIII -- Xref: bloom-picayune.mit.edu comp.fonts:5966 news.answers:3313 Path: bloom-picayune.mit.edu!snorkelwacker.mit.edu!news.media.mit.edu!micro-heart-of-gold.mit.edu!wupost!spool.mu.edu!caen!nic.umass.edu!dime!dime.cs.umass.edu!walsh From: walsh@cs.umass.edu (Norman Walsh) Newsgroups: comp.fonts,news.answers Subject: comp.fonts FAQ: part 1 of 5 Summary: This posting answers frequently asked questions about fonts. It addresses both general font questions and questions that are specific to a particular platform. Message-ID: <WALSH.92Oct2140516@ibis.cs.umass.edu> Date: 2 Oct 92 18:05:16 GMT Expires: 6 Nov 92 00:00:00 GMT Sender: news@dime.cs.umass.edu Reply-To: walsh@cs.umass.edu (Norm Walsh) Followup-To: poster Organization: Dept of Comp and Info Sci, Univ of Mass (Amherst) Lines: 1005 Approved: news-answers-request@MIT.Edu Archive-name: fonts-faq/part1 Version: 1.0.0 --- [cut here] --- FAQ for comp.fonts: section 1, part 1 of 2 --- FAQ for comp.fonts: Part I: General Info Version 1.0.0, Release 02OCT92 Welcome to the comp.fonts FAQ. This article, posted monthly, describes many of the basic questions that seem to be repeated frequently on comp.fonts. Your comments are both welcome and encouraged. The FAQ is divided into sections. The first section is a general overview. The remaining sections are more-or-less platform specific. The FAQ is posted in pieces to avoid clobbering news and/or mail gateways that are incapable of handling arbitrarily large items. The sections are: Part I: General Info Part II: Macintosh-specific Info Part III: MS-DOS-specific Info Part IV: *nix-specific Info Part V: Sun-specific Info Part VI: NeXT-specifc Info Part VII: X-specific Info Part VIII: Font utilities Even if you don't use a particular architecture, you may find it helpful to read the FAQ for that platform at least once. Some ideas, like font format conversion, may be relevant to more than one platform even if they are expressed in platform-specific tools at this time. After the FAQ is more stable, monthly DIFFs will be posted as well as the complete FAQ. This section is divided into the following topics: 0. Notes about the FAQ 1. What's the difference between type 1 fonts, type 3 fonts, type 5 fonts, Macintosh fonts, Windows fonts, TrueType fonts, LaserJet fonts, etc. 2. Where can I get <> fonts. 3. Where can I get fonts for non-Roman alphabets. 4. How can I convert my <> font to <> format? 5. Are fonts copyrightable? 6. File Formats / Font Formats / Ligatures / Standard Fonts / Glossary 7. Bibliography / Other Resources 8. Rules of Thumb 9. Acknowledgements 10. A brief introduction to typography ------------------------------------------------------------------------------ 0. Notes about the FAQ. Words printed in single quotes 'like this' will someday appear in the glossary. The glossary doesn't contain very much right now. This convention isn't followed very thoroughly at present. If you notice something that should be marked or something you feel should be in the glossary, please let us know. All trademarks are the trademarks of their respective owners. Standard disclaimers apply. The FAQ is maintained by Norm Walsh <walsh@cs.umass.edu> and Bharathi Jagadeesh <bjag@nwu.edu>. 1. What's the difference between type 1 fonts, type 3 fonts, type 5 fonts, Macintosh fonts, Windows fonts, LaserJet fonts, etc. This question is not trivial to answer. It's analogous to asking what the difference is between various graphics image file formats. The short, somewhat pragmatic answer, is simply that they are different ways of representing the same "information" and some of them will work with your software/printer and others won't. At one level, there are two major sorts of fonts: bitmapped and outline (scalable). Bitmapped fonts are falling out of fashion as various outline technologies grow in popularity and support. Bitmapped fonts represent each character as a rectangular grid of pixels. The bitmap for each character indicates precisely what pixels should be on and off. Printing a bitmapped character is simply a matter of blasting the right bits out to the printer. There are a number of disadvantages to this approach. The bitmap represents a particular instance of the character at a particular size and resolution. It is very difficult to change the size, shape, or resolution of a bitmapped character without significant loss of quality in the image. On the other hand, it's easy to do things like shading and filling with bitmapped characters. Outline fonts represent each character mathematically as a series of lines, curves, and 'hints'. When a character from an outline font is to be printed, it must be 'rasterized' into a bitmap "on the fly". PostScript printers, for example, do this in the print engine. If the "engine" in the output device cannot do the rasterizing, some front end has to do it first. GhostScript, for example, rasterizes the page before it displays it on the screen. Many of the disadvantages that are inherent in the bitmapped format are not present in outline fonts at all. Because an outline font is represented mathematically, it can be drawn at any reasonable size without significant loss of quality (at least, the loss of quality is not a direct consequence of resizing it--any font printed at a small enough size shows a significant loss of quality as the size approaches the resolution of the device). Additionally, because it is rasterized "on demand," the font can be adjusted for different resolutions and 'aspect ratios'. LaserJet .SFP and .SFL files, TeX PK, PXL, and GF files, Macintosh Screen Fonts, and GEM .GFX files are all examples of bitmapped font formats. PostScript Type 1, Type 3, and Type 5 fonts, Nimbus Q fonts, TrueType fonts, and LaserJet .SFS files are all examples of outline font formats. Neither of these lists is even close to being exhaustive. To complicate the issue further, identical formats on different platforms are not necessarily the same. For example Type 1 fonts on the Macintosh are not directly usable under MS-DOS or Unix, and vice-versa. Henry Schneiker <reachable electronically?> created the following description of the differences between several scalable font technologies. It has been pointed out that the following description shows signs of its age (for example, the eexec encryption has been thoroughly hacked). I don't dispute the observation and I encourage anyone with the knowledge and time to submit a more up to date description. It has further been suggested that this commentary is biased toward Kingsley/ATF. The omission of details about Bitstream (and possibly Bauer) may be considered serious since their software lies inside many 3rd-party PostScript interpreters. The moderators of this FAQ would gladly accept other descriptions/ explanations/viewpoints on the issues discussed in this (and every other) section. *-[Quote]-----------------------------------------------------------* There has been a lot of confusion about font technologies in recent times, especially when it comes to Type 1 versus Type 3 fonts, "hints," PostScript compatibility, encryption, character regularizing, kerning, and the like. Encryption (eexec) All fonts produced with Adobe's font technology are protected through data encryption. The decryption is provided by the `eexec' (encrypted execute) PostScript operator and, until recently, was only present in Adobe's licensed PostScript. Recently, RIPS reverse-engineered the eexec operator and now provides it to its licensees. Other clone vendors are sure to follow. It is important to note that the eexec operator can be used to decrypt and execute any valid PostScript statement. Therefore, any PostScript program or program fragment may be encrypted so it will work with eexec operator. You will further note that eexec is not tied to fonts in any way. While eexec is mostly used to protect font data, it can be used to protect any PostScript code. It just so happens that Adobe's favorite thing to protect is font data. The eexec operator is also used to hide the methods for applying patches to the PostScript system and methods for gaining privileged access to protected procedures. There is no gain in speed by encryption. In fact, there is a slight speed penalty resulting from decryption. The encrypted data is also twice as big as unencrypted data. This is compensated for in Adobe fonts by storing the hexadecimal characters (cipher text) as binary on the host disk. Type 1, Type 3, and Type 5 font formats There are generally three font formats used in Adobe PostScript printers: Type 1, Type 3, and Type 5. Type 1 fonts are Adobe's downloadable format. Type 3 fonts are third-party downloadable format. Type 5 fonts are the ROM-based fonts that are part of your printer. There is no functional difference between a Type 1, Type 3, or Type 5 font. A Type 3 font can do anything a Type 1 or Type 5 font can do. The only real difference between them is where the `BuildChar' routine comes from. For Type 1 and Type 5 fonts it's built into the printer. For Type 3 fonts it's built into the font. In other words, anything a Type 1 font can do a Type 3 font can also do. When PostScript is asked to generate a character, PostScript looks in the font's dictionary for FontType. If FontType is 1 or 5 PostScript executes an internal routine that knows how to interpret the font data stored in CharStrings. If FontType is 3 PostScript executes the routine BuildChar from the font's dictionary to interpret the font data (often stored in CharStrings). However, each BuildChar routine is written to read data formatted in a method convenient to the vendor. Adobe, Altsys, Bitstream, and Kingsley/ATF all format their font data differently and, hence, have different BuildChar routines. The font data for Adobe's Type 1 font format is a binary representation of the outline font data. Kingsley/ATF also uses a binary representation of its Type 3 outline font data and stores the binary code as binary on the host disk. Both company's binary representation and store technique substantially reduces the storage requirements on the host and in the printer. Other vendors, such as Altsys and Bitstream, also use a binary encoding system for their Type 3 outline font data. However the data is stored on the host as hexadecimal text characters and requires about double the storage as the binary storage technique. It should be noted that a compact text encoding (an alternate Altsys format) requires two to three times as much storage space as the binary storage technique. Type 5 fonts are special in that they often include hand-tuned bitmaps for the commonly used sizes, such as 10- and 12-point. Other sizes are generated from the outlines in normal fashion. Type 3 fonts can also be used to implement other font outline systems, such as Sun's F3 and Apple's B-spline. Type 1 and Type 5 fonts can only be used with the Adobe font format. Also, don't confuse Type 1, Type 3, and Type 5 fonts with Bitstream's Type A, Type B, Type C, and Type F. They are not the same and serve only to confuse the issue. Resolution `hints' When a character is described in outline format the outline has unlimited resolution. If you make it ten times as big, it is just as accurate as if it were ten times as small. However, to be of use, we must transfer the character outline to a sheet of paper through a device called a raster image processor (RIP). The RIP builds the image of the character out of lots of little squares called picture elements (pixels). The problem is, a pixel has physical size and can be printed only as either black or white. Look at a sheet of graph paper. Rows and columns of little squares (think: pixels). Draw a large `O' in the middle of the graph paper. Darken in all the squares touched by the O. Do the darkened squares form a letter that looks like the O you drew? This is the problem with low resolution (300 dpi). Which pixels do you turn on and which do you leave off to most accurately reproduce the character? All methods of hinting strive to fit (map) the outline of a character onto the pixel grid and produce the most pleasing/recognizable character no matter how coarse the grid is. Adobe's hinting system relies on regularizing (equalization) and straightening out the original character outline as much as possible when the font is created. Unfortunately this process of modifying the original font outlines for the sake of low resolution can badly distort the character from its original design. These distortions are visible when printing at high resolution. This system also places limitations on the placement of end points in the outline, again for the sake of the hinting system. The new Fontographer hinting system (a subset of Nimbus-Q) places similar restrictions on the character outline. for instance, to make proper use of the hints, a character must be (re)drawn with curve end points at curve maximum/minimum X/Y extents. In order for strokes to be equalized to the same widths, they must be (re)drawn with exactly the same widths. Again, the shape of the character is ruled by the limitations of the hinting system. The hinting system used by Kingsley/ATF in ATF Type Designer I* is fundamentally different. It does not require special placement of curve and end points in order to function. It also does not require modification of the original font outline to aid in grid fitting or stroke equalization. Once the outline has been created to the artist's satisfaction the hints for stroke equalization and grid fitting are added without any modification to the character outline. The net effect is that the Kingsley/ATF system does not sacrifice high-resolution quality while achieving low-resolution quality.